In the field of communications network management alarm reporting is important both in addressing immediate fault management issues related current infrastructure failures, and in the larger context of statistics reporting and network planning.
In a managed communication network context, large numbers of communications network nodes generate very large numbers of alarms which are logged. The alarm logs are collected into log files, the log files are subsequently interpreted, and the results are displayed to network management personnel interacting with network management equipment such a Network Management System (NMS). Efficient parsing of the log files in interpreting thereof, is important because of the large number of alarms and log files. Shortcomings in this regard represent large and costly operational network management overheads in provisioning communications services.
Complications arise from a lack of consistency in respect of alarm reporting. While attempts have been made to mitigate deficiencies, current solutions are either vendor specific addressing vendor specific needs and issues, or not widely adopted. Specifically shortcomings stem from:                the absence of a common format for alarm reporting;        the requirement to address multiple network management needs concurrently;        the absence of a common format for log files;        the difficulty in timely providing documentation regarding alarm reporting and file formats employed for timely development and/or update of alarm management tools; and        the onerous requirement to provide alarm management tools to take advantage of newly reported alarm information.        
In referring to a common format for alarm reporting, one understands an alarm report to include a sequenced group of tokens which specify in respect of an alarm, without being limited thereto: an alarm name, an alarm type, an alarm severity, an equipment component specification, a comment, etc. The sequence of the alarm tokens relates to the identification of the tokens. Each alarm report requires a different combination of such alarm tokens to fully convey the full meaning of the alarm and to distinguish it from others stifling any attempts towards alarm report standardization.
Network management functions, in addressing different aspects in responding to an alarm, require different sub-combinations of reported alarm tokens. Trying to address all network management functions with the same alarm report restricts independent development of network management functionality.
In order to support independent development of network management functionality, alarm reports are typically logged in different log files only with the necessary sub-combination of tokens needed to implement the network management functionality. However the practice introduces an alarm reporting overhead associated with reporting the same alarm multiple times, and further introduces complexities related to log file management.
Log files employed to support different network management functionality typically have different log file formats in respect of internal file structure including log file headers, the alarm log body, and any log file trailers. For example, the structure of a log file dictates the location where alarm reports start and end. Further alarm log file formats specify the manner in which alarm tokens are delimited such as: quote-comma delimiters wherein complex tokens containing spaces are placed between quotation marks and a coma is used between tokens, tab delimiters wherein complex tokens may include spaces and the tab character is used between tokens, etc.
Communications network equipment development includes multiple independent efforts of multiple communications network equipment vendors, wherein documentation has to be provided in respect of each effort for: each change in reporting an alarm, each new alarm, in respect of existing and newly developed communications network equipment. A development overhead is incurred in producing the documentation which is required to take into account the diverse network management functionality provided by network management systems.
The onerous requirement to provide alarm management tools to take advantage of newly reported alarm information relates to the diverse network management functions which are provided by a network management system. All network management functions have to be re-coded for each change in reporting an alarm, for each new alarm, for each change in a log file format, etc. in respect of existing and newly developed communications network equipment. In this respect, specialized log file parting code must be developed and updated with each alarm reporting change.
To date the most notable effort towards mitigating alarm reporting relates to an International Telecommunications Union Recommendation X.733 entitled “Information Technology, Open Systems Interconnection—System Management: Alarm Reporting Function” 1992 which is incorporated herein by reference. The X.733 recommendation specifies a mechanism for reliable alarm transport and relates to formatting tokens without addressing alarm report formatting nor alarm log file formatting. As a particular example the X.733 specification describes alarm token formats for:
Probable causeM;Specific problemsU;Perceived severityM;Backed-up statusU;Back-up objectC;Trend indicationU;Threshold informationC;Notification IdentifierU;Correlated notificationsU;State change definitionU;Monitored attributesU;Proposed repair actionsU;Additional textU;Additional informationU;etc.wherein “M” denotes a mandatory token; “U” denotes the token as a service-user option; “C” denotes a conditional token, conditions being defined by the text describing the token; “P” denotes a token having a value which is subject to constraints imposed by CCITT Recommendation X.710/ISO/IEC 9595. In order use the Rec. X.733 both the communications network equipment issuing alarm reports and the network management systems receiving the alarm reports have to employ the specification, agree on alarm report formats and alarm log file formation which are considered beyond the scope of the X.733 specification.
There therefore is a need to solve the above mentioned issues.